• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    The invention relates to monitoring at least one routing parameter of a cluster comprising nodes and switches, static communication links connecting nodes and switches. Each switch has multiple output ports. After selecting (400) at least one switch, a number of routes per port is calculated (410) for each port of each selected switch, routes being defined during a routing step to each connect one node to another. An average number of routes per port is then calculated (415) for the at least one selected switch. Each number of routes per calculated port is then compared (420) with the average number of routes per calculated port and, in response thereto, a potential cluster routing imbalance is notified (425).
    公开号:FR3025384A1
    申请号:FR1458250
    申请日:2014-09-03
    公开日:2016-03-04
    发明作者:Jean-Vincent Ficet；Sebastien Dugue；Jean-Olivier Gerphagnon
    申请人:Bull SA；
    IPC主号:
    专利说明:

    [0001] The present invention relates to routing in a cluster, that is to say the determination of communication routes between a set of nodes of the cluster, and more particularly a method for monitoring and alerting configuration of routing in a cluster. comprising static communication links as well as a computer program implementing this method. High Performance Computing, also known as High Performance Computing (HPC), is developing for both academic research and industry, particularly in technical fields such as aeronautics, energy, climatology and the sciences of life. In particular, modeling and simulation make it possible to reduce development costs and speed up the launch of innovative, more reliable and less energy-consuming products. For researchers, high performance computing has become an indispensable means of investigation.
    [0002] These calculations are generally implemented on data processing systems called clusters. A cluster typically comprises a set of interconnected nodes. Some nodes are used to perform compute tasks (compute nodes), others to store data (storage nodes), and one or more others manage the cluster (administrative nodes). Each node is for example a server implementing an operating system such as Linux (Linux is a brand). The connection between the nodes is, for example, carried out using Ethernet or InfiniBand communication links (Ethernet and InfiniBand are trademarks).
    [0003] Figure 1 schematically illustrates an example of a topology 100 of a cluster, type fat-tree. The latter comprises a set of generically referenced nodes 105. The nodes belonging to the set 110 are here calculating nodes while the nodes of the set 115 are service nodes (storage nodes and administration nodes ). The computing nodes can be grouped into subsets 120 called computing islands, the set 115 being called service island.
    [0004] The nodes are connected to each other by switches (called switches in English terminology), for example hierarchically. In the example illustrated in FIG. 1, the nodes are connected to first level switches 125 which are themselves connected to second level switches 130 which are in turn connected to third level switches 135. As illustrated in FIG. 2, each node generally comprises one or more microprocessors, local memories as well as a communication interface. More specifically, the node 200 here comprises a communication bus 202 to which are connected: - central processing units or microprocessors 204 (or CPU, acronym for Central Processing Unit in English terminology); RAM components (RAM, acronym for Random Access Memory in English terminology) comprising registers adapted to record variables and parameters created and modified during the execution of programs (as illustrated, each component of RAM can be associated with a microprocessor); and, communication interfaces 208 adapted to transmit and receive data. In this case, the node 200 also has internal storage means 212, such as hard disks, which can in particular comprise the executable code of programs. The communication bus allows communication and interoperability between the various elements included in the node 200 or connected to it. The microprocessors 204 control and direct the execution of the instructions or portions of software code or programs. When powering up, the program or programs that are stored in a non-volatile memory, for example a hard disk, are transferred into the RAM 206.
    [0005] It is observed here that the performance of a cluster is directly related to the choice of routes for the transfer of data between the nodes, established via communication links. In general, physical communication links are established between the nodes and the switches 5 during the hardware configuration of a cluster, the communication routes being themselves determined in an initialization phase from a definition of the nodes. connections to be established between the nodes. Depending on the communication technology implemented, the configuration of the routes can be static or dynamic.
    [0006] By way of illustration, the InfiniBand technology allows, in a cluster, a static configuration of the routes. This configuration uses static routing tables (or LFT, acronym for Linear Forwarding Table in English terminology) in each switch. When this technology is implemented, a routing algorithm such as the algorithms known as FTree, MINHOP, UPDN and LASH can be used. The choice of the algorithm to be used is typically done by an administrator according to, inter alia, the topology of the cluster. It may be, for example, the FTree algorithm. However, if the chosen algorithm does not make it possible to carry out the routing, the cluster manager (typically in charge of the routing) usually automatically chooses another algorithm, for example the MINHOP algorithm (generally less efficient than that initially chosen). ). As an illustration and in a simplified way, the FTree algorithm determines routes so that they are distributed as much as possible through the existing communication links. For these purposes, when routing a fully connected communication network according to a fat-tree architecture, each node of the network is considered to have the same importance. Thus, when a route is established between two nodes of the same link, the number of routes using this link, called the link load 30, is increased by one. When the routing algorithm tries to establish a new route and there are several possibilities, it compares the load levels associated with the links on which these possibilities are based and selects the one with the links with the lowest load level. . During use of the cluster, if a link or item such as a node or switch fails, new routing is performed. Since routing quality has a direct influence on cluster performance, there is a need to monitor a routing configuration in a cluster that includes static communication links and, if necessary, alert an administrator of a potential problem. of routing. The invention solves at least one of the problems discussed above. The invention thus relates to a method for computer monitoring at least one routing parameter of a cluster comprising a plurality of nodes and a plurality of switches, static communication links connecting nodes and switches of said pluralities nodes and switches, each switch comprising a plurality of output ports, characterized in that it comprises the following steps; selecting at least one of said plurality of switches; calculating a number of routes per port for each port of each selected switch, routes being defined during a routing step to link each one node to another; Calculating an average number of routes per port for the at least one selected switch; - comparing each number of roads per calculated port with the average number of routes per calculated port; and in response to said comparison, notifying a potential routing imbalance of said cluster.
    [0007] The method according to the invention thus makes it possible to detect and notify a potential routing problem that may cause a drop in the performance of the cluster. According to a particular embodiment, each switch 5 comprises a routing table for identifying a port according to a characteristic of a received data packet, the method further comprising a step of obtaining a routing table for each selected switch. said step of calculating a number of routes per port for each port of each selected switch is based on a routing table obtained for each selected switch. According to a particular embodiment, said step of comparing each number of roads per port with the average number of routes per port comprises a step of calculating the difference of each number of roads per port with the average number of routes per port and a step of comparing the difference with at least one threshold. According to a particular embodiment, said step of calculating the difference of each number of roads per port with the average number of routes per port is a step of calculating the absolute value of the difference of each number of roads per port with the average number of routes per port.
    [0008] According to a particular embodiment, the difference between each number of roads per port and the average number of roads per port is considered to be zero if it is negative. According to a particular embodiment, said comparison of the difference with at least one threshold comprises a step of selecting a first or a second threshold depending on whether the difference is positive or negative. According to a particular embodiment, the method further comprises the following steps: identification of a selected algorithm for routing said cluster; - identification of an algorithm used to route said cluster; and 30 - if the identifiers of said selected algorithm and said algorithm used to route said cluster are different, notification of a potential routing optimization problem of said cluster.
    [0009] According to a particular embodiment, the method loops on itself to identify a potential problem of routing of said cluster. According to a particular embodiment, the method is implemented in an InfiniBand type cluster manager.
    [0010] The invention also relates to a computer program comprising instructions adapted to the implementation of each of the steps of the method described above when said program is executed on a computer as well as a means of storing information, removable or not, partially or fully readable by a computer or a microprocessor 10 having code instructions of a computer program for performing each of the steps of the method previously. The advantages provided by this computer program and this means of storing information are similar to those mentioned above. Other advantages, objects and features of the present invention will become apparent from the following detailed description, given by way of non-limiting example, with reference to the accompanying drawings, in which: FIG. 1 illustrates an exemplary topology of a cluster; FIG. 2 illustrates an exemplary architecture of a node of a cluster; FIG. 3, comprising FIGS. 3a and 3b, illustrates an example of links between several switches when the routing is considered as balanced and when it is not, respectively; FIG. 4 illustrates certain steps of an exemplary algorithm for estimating a representative value of the routing balancing of a cluster and, if necessary, alerting an administrator of a potential imbalance; and FIG. 5 illustrates certain steps of an exemplary algorithm for alerting an administrator if there is a risk of routing that does not allow the operation of a cluster in its best conditions. It has been observed that the routing quality of a cluster can be estimated according to the homogeneity of the distribution of the roads on the links between the different elements of this cluster. In other words, a uniform distribution of routes on the links leads to a uniform distribution of data exchange charges across the cluster, making it possible to avoid overuse of certain links and underutilization of others. links, which typically leads to congestion and increased latency.
    [0011] The distribution of the roads on the links thus represents a quality index of routing and more generally an index of quality of use of the elements of the cluster. Furthermore, it is recalled that the routing of data in an InfiniBand network, in the form of data packets, is based on a local relay mechanism according to a destination indication called LID (acronym for Local IDentifier in English terminology). Saxon). Thus, each InfiniBand switch (comprising several input ports and several output ports) decides on which output port a packet should be transmitted according to the destination indication (LID) of the packet in question.
    [0012] For these purposes, each switch uses a local routing table called LFT (Linear Forwarding Table). Such tables, constructed during a routing step by a routing module and transmitted to each switch, establish a link between a destination indication (LID) of a data packet and an output port of the switch with which the packet is associated. routing table considered. In other words, a local routing step of an InfiniBand switch consists of a set of pairs each comprising a routing indication (LID) and an output port reference. An example of such a routing table is given in the appendix (Table 1).
    [0013] When an InfiniBand switch receives a packet of data, the header of the packet is scanned for a destination indication (LID). The routing table is then consulted to determine the output port reference associated with this destination indication. The packet is then transmitted to its destination via the output port whose reference has been determined from the destination indication. Thus, for example, if a packet having, in its header, a destination indication equal to 28, arrives in an InfiniBand switch whose routing table corresponds to the attached table 1, this packet is retransmitted via the output port having the reference 25. As previously indicated, the routing of an InfiniBand cluster is static, which means that the routes are predictable and do not change until the cluster is shut down or an equipment or link fails, leading to a re-routing of the cluster. It is typically performed by a routing module InfiniBand manager, called InfiniBand Subnet Manager, which is responsible for calculating the switch routing tables and transmit them.
    [0014] The InfiniBand manager generally offers several routing algorithms each having particular characteristics. The choice of an algorithm is usually made by an administrator according to the topology of the cluster. Thus, for example, the choice of the administrator may relate to the algorithm known as FTree which is particularly effective for clusters having a fat-tree topology. If the InfiniBand Manager fails in cluster routing with the selected algorithm, a lower performing algorithm is automatically selected, for example the algorithm known as MinHop. When there are several communication links between two switches, the routing is considered balanced between these two switches, if there is the same number of routes per link. Conversely, routing is not considered balanced if there is not the same number of routes per link or if the number of routes per link varies beyond a predetermined threshold or calculated dynamically.
    [0015] FIG. 3, comprising FIGS. 3a and 3b, illustrates an example of links between several switches when the routing is considered to be balanced and when it is not, respectively. As illustrated in FIG. 3a, cluster 100 here comprises a first set of nodes referenced 105-11 to 105-1n, a second set of nodes referenced 105-p1 to 105-pm as well as four switches 110-1 to 110- 4. Each node of the first set is connected to the switch 110-1 by a specific link. Likewise, each node of the second set is connected to the switch 110-2 by a specific link. The switch 110-1 is connected to the switch 110-3 by two links 115-1 and 115-2 and the switch 110-4 by two links 115-3 and 115-4. In a symmetrical manner, the switch 110-2 is connected to the switch 110-3 by two links 115-5 and 115-6 and to the switch 110-4 by two links 115-7 and 115-8. As shown in FIG. 3a, each of the links 115-1 to 115-8 comprises 8 routes. Therefore, the number of routes per link is the same for all links, the routing is considered balanced. FIG. 3b represents a cluster 100 'similar to the cluster 100 illustrated in FIG. 3a. Here it comprises two sets of nodes (105'-11 to 105'-1 n and 105'-pl to 105'-pm) as well as four switches (110'-1 to 110'-4). Each node of the first and second sets is connected to the switches 110'-1 and 110'-2, respectively, by a specific link. The switch 110'-1 is connected to the switches 110'-3 and 110'-4 by the two links 115'-1 and 115'-2 and the two links 115'-3 and 115'-4, respectively. In a symmetrical manner, the switch 110'-2 is connected to the switches 110'-3 and 110'-4 by the two links 115'-5 and 115'-6 and the two links 115'-7 and 115'-8, respectively. As shown in Fig. 3b, the links 115'-1 and 115'-2 comprise 4 and 12 routes, respectively, while each of the links 115'-3 to 115'-8 comprises 8 routes. The number of routes per link is not the same for all links, the routing is not considered balanced. Thus, the routing quality of a cluster is here determined according to the distribution of routes by switch port, for each switch, for all switches of a group of switches (for example all switches directly connected to one or more given items) or for all switches in the cluster. For these purposes, according to a particular embodiment, the routing table of each switch is analyzed to calculate the number of routes per port, for each port of the switch in question. This analysis can be performed by the InfiniBand manager. As an illustration, the routing table given in the appendix (table 1) can be used to calculate the number of routes assigned to each output port of the corresponding switch. Table 2 in the appendix shows the number of routes for each port. As indicated, five routes are assigned to port 21, three routes are assigned to port 19 and one route to other ports.
    [0016] Thus, knowing the routing table of all the switches of the cluster, the InfiniBand manager or another monitoring module can calculate the number of routes assigned to each output port of each switch and deduce a balancing information from the routing of the switch. cluster. Figure 4 illustrates some steps of an exemplary algorithm for estimating a representative value of the routing balancing of a cluster and, if necessary, alerting an administrator of a potential imbalance. This algorithm can, for example, be implemented in an InfiniBand manager. As illustrated, a first step (step 400) is to select switches C1 (i ranging from 1 to the number NbC of selected switches). The selection can be for a single switch, all switches in a group (for example, all switches directly connected to one or more given elements) or all switches in the cluster. The selection can be carried out automatically according to predetermined criteria, manually by an administrator or in a mixed manner (a pre-selection being for example proposed to an administrator who can validate it and, if necessary, modify it). In a next step, the routing table (TRi) associated with each selected switch is obtained (step 405). It is observed here that if the algorithm is implemented in an InfiniBand manager, obtaining these tables is made particularly easy because it is the InfiniBand manager that determines them. If the algorithm is implemented in another module, the routing tables may be obtained by requests from the switches concerned, from the module or modules having created them or from any other device storing them. For each selected switch, the number of routes per output port NbRij (j ranging from 1 to the number NbPi of the output ports of the switch Ci) is calculated from the routing table associated with this switch (step 410). As previously indicated, the number of routes per link can be determined by counting the number of different destination indications (LIDs) associated with the same output port of a switch.
    [0017] The average number of routes per NbR port is then calculated for all the selected switches (step 415). This number is typically calculated according to the following relationship: NbC Nb 11) i NbRij NbR = Nbpi It is observed here that the granularity of the representative value of the cluster routing balancing is determined by all the 10 selected switches. As indicated in FIG. 4 by the dotted line arrow, the algorithm can be repeated for several sets of switches (and therefore for each switch considered in isolation). In a next step, the number of routes NbRij for each port j of each switch i is compared with the average number NbR of routes per port (step 420). If the difference between the number of routes NbRij of the port j of the switch i and the average number NbR of routes per port exceeds a threshold 0, it is considered that the routing of the cluster is unbalanced. In this case, a notification is sent to an administrator (step 425), for example as an e-mail message. The notification may include an indication of the switch (s) concerned and, if appropriate, the port (s) of the latter (s) for which a potential problem is detected. The threshold 0 beyond which it is considered that the routing of the cluster 25 is unbalanced is, in theory, close to zero. However, in practice, it is preferably determined by the administrator according to the topology of the cluster and its load (related, in particular, to the number and nature of the applications executed). It is observed here that if it appears that a load problem is essentially related to an overload of a link (when the number of routes 3025384 12 NbRij of the port j of the switch i is greater than the average number NbR of routes by port), which can lead to congestion and / or increased latency, underloading a link (when the number of routes NbRij of port j of switch i is less than the average number NbR of routes per port) indicates that there is an overhead elsewhere in the cluster, this overhead may not be detected (due to overload distribution over multiple links). Naturally, it is possible to detect only the overloads (NbRij - NbR> 0), or even the underloads (NbR - NbRij> 0), or even the 10 overloads and the sub-loads with different thresholds (NbRij - NbR > 01 or NbR - NbRij> 02). According to another embodiment, the routing algorithm used is taken into account to alert an administrator of a potential routing problem.
    [0018] FIG. 5 illustrates certain steps of an exemplary algorithm for alerting an administrator if there is a risk of routing that does not allow the operation of a cluster in its best conditions. In particular, the algorithm illustrated in FIG. 5 makes it possible to alert an administrator if the routing algorithm used is not the routing algorithm selected (or validated) by an administrator and / or if there is a potential unbalance routing in the cluster. This algorithm can notably be implemented in an InfiniBand manager. As illustrated, a first step here is to identify the routing algorithm selected or validated by an administrator (ARS) to route the cluster (step 500). An identifier of this selected or validated algorithm can be obtained from the configuration parameters of the cluster administration module, for example an InfiniBand manager. Such an identifier may, for example, be the "FTREE" identifier designating the routing algorithm known as FTree.
    [0019] Then, before or in parallel, the routing algorithm actually used (ARU) to route the cluster is identified (step 505). Again, an identifier of this used algorithm can be obtained from the configuration parameters of the cluster administration module, for example an InfiniBand manager. Such an identifier may, for example, be the identifier "MINHOP" designating the routing algorithm known as MINHOP. The identifier of the routing algorithm used is then compared to the selected routing algorithm (step 510). If these identifiers are different, a notification is sent to an administrator (step 515), for example in the form of an electronic message, indicating that the routing algorithm used is not the selected routing algorithm and also mentioning preferably, a reference of the routing algorithm used (and, optionally, a reference of the selected routing algorithm). On the contrary, if the identifier of the routing algorithm used is the same as that of the selected routing algorithm (step 510), steps are performed to estimate a representative value of the routing balancing of a cluster and, where appropriate, alerting an administrator of potential imbalance. These steps, referenced 400 'to 420', can be similar to the steps 400 to 420 described with reference to FIG. 4. As described above, the step 400 'is for the automatic, semi-automatic or manual selection of a or several switches Ci (i varying from 1 to the number NbC of selected switches). The routing table (TRi) associated with each selected switch is obtained in a next step (step 405 ') being again observed here only if the algorithm is implemented in an InfiniBand manager, obtaining these tables is made particularly easy because it is the InfiniBand manager that determines them. If the algorithm is implemented in another module, the routing tables can be obtained by request from the switches concerned, from the module or modules having created them or from any other device storing them. For each selected switch, the number of routes per port NbRij (j varying from 1 to the number NbPi of ports of the switch Ci) is here calculated from the routing table associated with this switch (step 410 '). As previously indicated, the number of routes per link can be determined by counting the number of different destination indications (LIDs) associated with the same port of a switch. The average number of routes per NbR port is then calculated for all the selected switches (step 415 '). Again, this number is typically computed according to the following relation: ## EQU1 ## the granularity of the representative value of the cluster routing balancing being determined by the set of selected switches. In a next step, the number of routes NbRij for each port j of each switch i is compared with the average number NbR of routes 10 per port (step 420 '). If the difference between the number of routes NbRij of the port j of the switch i and the average number NbR of routes per port exceeds a threshold e, it is considered that the cluster that the routing of the cluster is unbalanced. In this case, a notification is sent to an administrator (step 515), for example as an e-mail message. Again, the notification may include an indication of the switch (s) and possibly the port (s) thereof, for which a potential problem is detected. Here again, it is possible to detect only the overloads (NbRij - 20 NbR> 0), the underloads (NbR - NbRij> 0), or the overloads and the sub-loads with different thresholds (NbRij - NbR > 01 or NbR - NbRij> e2). As illustrated in FIG. 5, the algorithm preferably loops on itself until it is terminated. It thus makes it possible to alert an administrator if there is a risk of routing which does not allow the operation of a cluster in its best conditions during the use of the latter. It should be noted that the algorithms described with reference to FIGS. 4 and 5 may, for example, be implemented in a device similar to that described with reference to FIG. 2, in the form of a computer program. Naturally, to meet specific needs, a person skilled in the art of the invention may apply modifications in the foregoing description.
    权利要求:
    Claims (10)
    [0001]
    REVENDICATIONS1. A computer method for monitoring at least one routing parameter of a cluster comprising a plurality of nodes and a plurality of switches, static communication links connecting nodes and switches of said plurality of nodes and switches, each switch comprising a plurality of output ports, which method is characterized by comprising the following steps; selecting (400) at least one of said plurality of switches; calculating (410) a number of routes per port for each port of each selected switch, routes being defined during a routing step to each connect one node to another; calculating (415) an average number of routes per port for the at least one selected switch; comparing (420) each number of roads per calculated port with the average number of routes per calculated port; and in response to said comparison, notifying (425) a potential routing imbalance of said cluster.
    [0002]
    The method of claim 1 wherein each switch comprises a routing table for identifying a port according to a characteristic of a received data packet, the method further comprising a step of obtaining (405) a routing table for each selected switch, said step of calculating a number of routes per port for each port of each selected switch is based on a routing table obtained for each selected switch.
    [0003]
    The method of claim 1 or claim 2 wherein said step of comparing each number of routes per port with the average number of routes per port comprises a step of calculating the difference of each number of routes per port with the average number of 3025384 18 routes per port and a step of comparison of the difference with at least one threshold.
    [0004]
    The method of claim 3 wherein said step of calculating the difference of each number of routes per port with the average number of routes per port is a step of calculating the absolute value of the difference of each number of routes per port with the average number of routes per port.
    [0005]
    The method of claim 3 wherein the difference between each number of routes per port and the average number of routes per port is considered to be zero if it is negative.
    [0006]
    The method of claim 3 wherein said comparing the difference with at least one threshold comprises a step of selecting a first or a second threshold depending on whether the difference is positive or negative.
    [0007]
    The method of any one of claims 1 to 6 further comprising the steps of: identifying (500) a selected algorithm for routing said cluster; identifying (505) an algorithm used to route said cluster; and 20 - if the identifiers of said selected algorithm and said algorithm used to route said cluster are different, notifying (515) of a potential routing optimization problem of said cluster.
    [0008]
    The method of any one of claims 1 to 7 wherein the method loops over itself to identify a potential routing problem of said cluster.
    [0009]
    9. Method according to any one of claims 1 to 8, the method being implemented in an InfiniBand type cluster manager.
    [0010]
    A computer program comprising instructions adapted to implement each of the steps of the method of any one of the preceding claims when said program is run on a computer.
    类似技术:
    公开号 | 公开日 | 专利标题
    EP3189636B1|2018-11-07|Method of monitoring and of warning of routing configuration in a cluster comprising static communication links and computer program implementing this method
    US9148381B2|2015-09-29|Cloud computing enhanced gateway for communication networks
    US10055262B1|2018-08-21|Distributed load balancing with imperfect workload information
    US10764165B1|2020-09-01|Event-driven framework for filtering and processing network flows
    US20130166739A1|2013-06-27|Localization Of Peer To Peer Traffic
    FR2903548A1|2008-01-11|METHOD FOR AUTOMATICALLY CONTROLLING A TELECOMMUNICATIONS NETWORK WITH LOCAL KNOWLEDGE MUTUALIZATION
    CN108063814A|2018-05-22|A kind of load-balancing method and device
    FR2960369A1|2011-11-25|METHOD FOR OPTIMIZING ROUTING IN A CLUSTER COMPRISING STATIC COMMUNICATION LINKS AND COMPUTER PROGRAM USING SAID METHOD
    WO2019115173A1|2019-06-20|Device and process for checking sensors that permit the detection of intrusions into a network
    US20210012239A1|2021-01-14|Automated generation of machine learning models for network evaluation
    EP3191950A1|2017-07-19|Allocation of resources
    CN106657333B|2020-09-22|Centralized directory data exchange system and method based on cloud service mode
    JP2015037198A|2015-02-23|Bus recovery control device
    FR2834409A1|2003-07-04|SYSTEM FOR MANAGING TRANSPORT NETWORKS BASED ON THE ANALYSIS OF TRENDS OF DATA ACQUIRED ON THE NETWORK
    WO2013050682A1|2013-04-11|Pseudo-dynamic adaptive routing method in a cluster including static communication links, and computer program implementing said method
    EP3231137B1|2020-07-15|Overlay network for communication network connecting data centres of a cloud services provider
    CN111935457B|2021-04-13|Intelligent storage system
    FR2960732A1|2011-12-02|METHOD FOR PSEUDO-DYNAMIC ROUTING IN A CLUSTER COMPRISING STATIC COMMUNICATION LINKS AND COMPUTER PROGRAM USING THE SAME
    CN106888237A|2017-06-23|A kind of data dispatching method and system
    US11178014B1|2021-11-16|Establishment and control of grouped autonomous device networks
    EP3216175B1|2019-01-09|Method of distant monitoring and control of a cluster using a communication network of infiniband type and computer programme implementing this method
    WO2013088019A1|2013-06-20|Method and computer program for managing multiple faults in a computing infrastructure comprising high-availability equipment
    US20210185119A1|2021-06-17|A Decentralized Load-Balancing Method for Resource/Traffic Distribution
    GB2373961A|2002-10-02|Apparatus and method for detection of server-like devices within a network
    FR3003109A1|2014-09-12|METHOD OF CONGESTION CONTROL FOR TELECOMMUNICATIONS NETWORKS
    同族专利:
    公开号 | 公开日
    ES2709503T3|2019-04-16|
    US10110464B2|2018-10-23|
    WO2016034797A1|2016-03-10|
    FR3025384B1|2016-09-16|
    US20170289016A1|2017-10-05|
    EP3189636B1|2018-11-07|
    EP3189636A1|2017-07-12|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    WO2011144848A1|2010-05-20|2011-11-24|Bull Sas|Method of optimizing routing in a cluster comprising static communication links and computer program implementing this method|
    US7426210B1|2001-04-03|2008-09-16|Yt Networks Capital, Llc|Port-to-port, non-blocking, scalable optical router architecture and method for routing optical traffic|
    CN101855622A|2007-11-09|2010-10-06|多数有限公司|Shared memory system for a tightly-coupled multiprocessor|
    CN101216815B|2008-01-07|2010-11-03|浪潮电子信息产业股份有限公司|Double-wing extendable multi-processor tight coupling sharing memory architecture|
    US8065433B2|2009-01-09|2011-11-22|Microsoft Corporation|Hybrid butterfly cube architecture for modular data centers|
    US9130858B2|2012-08-29|2015-09-08|Oracle International Corporation|System and method for supporting discovery and routing degraded fat-trees in a middleware machine environment|
    EP3213471B1|2014-10-31|2018-08-29|Oracle International Corporation|System and method for supporting partition-aware routing in a multi-tenant cluster environment|US10348649B2|2016-01-28|2019-07-09|Oracle International Corporation|System and method for supporting partitioned switch forwarding tables in a high performance computing environment|
    US10659340B2|2016-01-28|2020-05-19|Oracle International Corporation|System and method for supporting VM migration between subnets in a high performance computing environment|
    US10536334B2|2016-01-28|2020-01-14|Oracle International Corporation|System and method for supporting subnet number aliasing in a high performance computing environment|
    US10333894B2|2016-01-28|2019-06-25|Oracle International Corporation|System and method for supporting flexible forwarding domain boundaries in a high performance computing environment|
    US10355972B2|2016-01-28|2019-07-16|Oracle International Corporation|System and method for supporting flexible P_Key mapping in a high performance computing environment|
    US10348847B2|2016-01-28|2019-07-09|Oracle International Corporation|System and method for supporting proxy based multicast forwarding in a high performance computing environment|
    US10666611B2|2016-01-28|2020-05-26|Oracle International Corporation|System and method for supporting multiple concurrent SL to VL mappings in a high performance computing environment|
    US10616118B2|2016-01-28|2020-04-07|Oracle International Corporation|System and method for supporting aggressive credit waiting in a high performance computing environment|
    US10630816B2|2016-01-28|2020-04-21|Oracle International Corporation|System and method for supporting shared multicast local identifiersranges in a high performance computing environment|
    US10581711B2|2016-01-28|2020-03-03|Oracle International Corporation|System and method for policing network traffic flows using a ternary content addressable memory in a high performance computing environment|
    法律状态:
    2015-08-27| PLFP| Fee payment|Year of fee payment: 2 |
    2016-03-04| PLSC| Search report ready|Effective date: 20160304 |
    2016-08-22| PLFP| Fee payment|Year of fee payment: 3 |
    2017-08-22| PLFP| Fee payment|Year of fee payment: 4 |
    2018-09-28| PLFP| Fee payment|Year of fee payment: 5 |
    2019-09-25| PLFP| Fee payment|Year of fee payment: 6 |
    2020-09-28| PLFP| Fee payment|Year of fee payment: 7 |
    2021-09-27| PLFP| Fee payment|Year of fee payment: 8 |
    优先权:
    申请号 | 申请日 | 专利标题
    FR1458250A|FR3025384B1|2014-09-03|2014-09-03|METHOD FOR MONITORING AND ROUTING CONFIGURATION ALERT IN A CLUSTER COMPRISING STATIC COMMUNICATION LINKS AND COMPUTER PROGRAM USING SAID METHOD|FR1458250A| FR3025384B1|2014-09-03|2014-09-03|METHOD FOR MONITORING AND ROUTING CONFIGURATION ALERT IN A CLUSTER COMPRISING STATIC COMMUNICATION LINKS AND COMPUTER PROGRAM USING SAID METHOD|
    US15/508,363| US10110464B2|2014-09-03|2015-08-31|Method of monitoring and warning for configuring routing in a cluster comprising static communication links and computer program implementing that method|
    EP15771674.7A| EP3189636B1|2014-09-03|2015-08-31|Method of monitoring and of warning of routing configuration in a cluster comprising static communication links and computer program implementing this method|
    PCT/FR2015/052298| WO2016034797A1|2014-09-03|2015-08-31|Method of monitoring and of warning of routing configuration in a cluster comprising static communication links and computer program implementing this method|
    ES15771674T| ES2709503T3|2014-09-03|2015-08-31|Monitoring and alerting procedure for routing configuration in a group that includes static communication links, and computer program that implements this procedure|
    [返回顶部]